.\chapter{Une Architecture repensée}

\section{L'API}



\section{La Base de données}

Afin de stocker certaines informations, nous utilisons une base de données sur le modèle relationnel. Par défaut nous utilisons une base de données SQLite via SQLAlchemy.

\subsection{Simplification de la base de données}

L'idée de base était de stocker la suite de scripts de tests à effectuer dans la base de données pour pouvoir facilement l'associer à un assignment. Néanmoins, pour l'intégration des plugins nous avions utilisé l'arborescence sur le disque pour stocker les informations. Cette méthode de stockage pouvait tout à fait être appliquée aux tests et rendait ainsi les tables associées dans la base de donnée inutiles. Ceci allégeait donc le traitement lié à la base de données en le remplaçant par un parcours d'arborescence lors de chaque test.

La nouvelle base de données est donc ainsi:

\includegraphics[scale=0.67]{schema_relationnel_bdd_interne_final}

\subsection{Couche de dialogue avec SQLAlchemy}



\section{Le Core}

L'appelation "core" définie le noyau de SPASS.  Ce core constitue le minimum utile pour le bon fonctionnement de l'application.

\subsection{Les Builtins}

Les builtins sont les fonctions incluses dans SPASS. Elles permettent d'initialiser l'application pour son bon fonctionnement ainsi que de manipuler les données gérées par le programme. Il est impossible de rajouter un builtin sans toucher au code, ce qui les différencies des plugins. Actuellement chaque commande builtin est dans son propre fichier python sauf les commandes builtins et plugins.
Les builtins sont au nombre de 9:
\begin{itemize}
\item add : créé des templates, assignments, users dans la base de données en faisant le lien avec les dossier contenus dans le warehouse.
\item builtin : liste les commandes builtin disponibles.
\item export : commande permettant de récuperer un assignment depuis le warehouse.
\item help : permet d'obtenir une aide quand à la manière d'utiliser spass (en ligne de commande).
\item info : permet de lire les informations relatives au users, team et teamset contenues dans la base de données.
\item init : cette fonction créé l'environnement d'execution si spass viens d'être installé (création de la base de données et du warehouse). 
\item list : liste le contenue de la table spécifiée dans la base de données ou encore les informations contenues dans l'arborescence du warehouse. 
\item plugin : liste les commandes rajoutées en tant que plugin disponibles.
\item remove : suppression d'une entrée dans la base de données ou d'un dossier dans le warehouse.
\item search : recherche d'un utilisateur au moyen d'expressions régulières.
\item test : lance les tests associés a un assignment sur une version d'une team, sur la derniere version d'une team, ou sur les dernieres versions de toutes les teams.
\end{itemize}

\subsection{Les Plugins}

Les plugins sont des commandes externes qui peuvent être rajoutées. Ces commandes doivent être placées dans un répertoire à leur nom dans le dossier /spass/plugins/commands.
Afin d'être correctement lancées par spass deux points sont à respecter.
\begin{itemize}
\item un fichier \_\_init\_\_.py doit être ajouté pour gérer les dépendances.
\item une fonction run() prenant une parametre une liste de chaine de caractères doit exister dans un fichier main.py.
\end{itemize}
La fonction run sera appelée par spass pour lancer le plugin, il est donc impératif qu'elle existe.
Les plugins peuvent utiliser les api de spass sans aucun problème.

\subsection{Les Tests}

Les tests sont constitués d'une suite de scripts python et, optionnellement, de dossiers aux noms identiques. Le fonctionnement est simple, les scripts étant lancés dans l'ordre, et si l'un d'entre eux réussi, spass regarde s'il existe un dossier contenant le même nom. Si c'est le cas les tests contenus dans ce dossiers sont exécutés et ainsi de suite. Dans le cas où le test échoue, le dossier n'est pas examiné et on exécute le test suivant.
Les tests doivent être contenus dans le template auxquel ils sont associés et seront stockés dans le warehouse.

\subsection{Extensibilité}

L'un des principaux buts du projet était de permettre une grande extensibilité grâce aux mécanisme de plugins qui permettra au programme d'évoluer sans que le coeur n'ait à être recodé.

\subsubsection{Gestion hiérarchique dynamique}

La recherche dynamique de plugins ou de tests via l'arborescence nous permet d'assurer une simplicité d'intégration et d'utilisation. En effet, il n'est nul besoin de stocker les informations y faisant référence, l'arborescence les stockant naturellement. 
De plus, le parcours hiérarchique dynamique nous assure une autre fonctionnalité: l'intégration "à chaud" de nouveaux plugins ou de nouveaux tests. Ainsi, entre deux parcours il est tout à fait possible de rajouter un fichier sans que spass ne ressente la moindre différence. Ceci permet d'éviter d'avoir à relancer le programme en cas de rajout et permet en outre à plusieurs personnes de rajouter des fonctionnalités en même temps sans qu'ils ne se perturbent l'un l'autre.

\subsubsection{Gestion de l'internationalisation}

L'internationalisation est un paramètre à prendre en compte lorsque l'on parle d'extensibilité. Pour ce faire, les messages et messages d'erreurs retournés par spass peuvent être changé selon la langue. Il suffit de rajouter une table contenant la traduction dans la langue voulues dans les fichiers errors.py et message.py. 
Ces fichiers agissent de manière au fichier errno du langage C en associant un code d'erreur à une chaîne de caractères à afficher.
Il est toutefois bon de rappeler que les plugins doivent gérer eux même leur internationalisation, car seuls les messages internes à spass sont traités.

\section{Le Warehouse}

Le warehouse est l'espace de stockage de spass, structuré selon une hiérarchie précise qui répond à ses besoins.

\subsection{Rôle du warehouse}

Le terme warehouse désigne une partie de l'arborescence servant à stocker tout les fichiers extérieurs dont l'application peut avoir besoin, tels que les programmes à tester, les scripts de tests à appliquer, les templates et assignment, etc. Cette partie agit donc comme un simple espace de stockage privé, géré par spass.
Il est à noter que dans une version précèdente de l'architecture de spass, les informations relatives aux tests étaient stockés dans la base de données, alors que nous utilisons ici l'arborescence du système de fichier mis en place pour obtenir le même résultat.

\subsection{Description de la hiérarchie}

Le warehouse est composé de deux dossiers principaux: \/template et \/assignment.

Le dossier \/template contient les données relative à la création d'un assignment. Une suite de dossiers numérotés symbolise chaque template.
Chaque template doit possèder un dossier \/tests contenant les tests à effectuer avec la hiérarchie correspondante.
Le dossier \/assignment contient une suite d'assignment contenus dans des dossiers numérotés. Chaque assignment possède une copie des tests contenu dans le template dont il est issue, ainsi qu'un dossier par équipe qui le compose.

La encore, chacune de ces équipes est définies par une suite de dossiers numérotés, chacun spécifiant une version du projet afin d'eng arantir l'historisation.
Chaque version est composée d'un dossier \/files englobant les fichiers uploadés par le groupe devant être testés, et d'un dossier \/test contenant les résultats des tests effectués sur cette version (vide, si aucun test n'est effectué sur cette version). 

